Skip to main content

CVE-2025-53499

➡ Information Leak​

Summary​

  • 제품 : Wikimedia Foundation MediaWiki – AbuseFilter Extension
  • 영향 범위 : 1.43.X before 1.43.2 가 영향 받음 (NVD)
  • 취약점 종류
    • CWE-862 – Missing Authorization → AbuseFilter의 abusefiltercheckmatch API가 “보호된 변수(protected variables)” 접근 권한을 확인하지 않고 필터 매칭을 수행함 (NVD)
    • 공격자가 볼 수 없어야 하는 변수 값(예: IP 관련 변수)을 “조건이 맞는지 여부(boolean)”를 통해 간접적으로 추론 가능 → 정보 유출 + 정책 우회 가능성
  • 결과
    • 권한이 없는 사용자가 AbuseFilter 로그/RecentChanges의 protected 변수 값에 대해 “맞다/틀리다”를 물어볼 수 있음
    • 반복적인 질의를 통해 실제 값(IP 등 민감 정보)을 유추할 수 있음
    • AbuseFilter가 의도한 권한 기반 보호(Access Control)가 붕괴되는 형태의 정보 유출
  • CVSS(3.1) : 9.1 Critical (AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:N) (cve.ics-csirt.io)

1. 취약점 사례 조사​

a. 스택 & 아키텍쳐​

  • MediaWiki 코어 + AbuseFilter 확장하여 활용
    • PHP 기반의 위키엔진인 MediaWiki 위에 동작하는 확장 기능 활용
    • AbuseFilter는 편집, 수정 등의 행위에 대한 규칙 기반 필터를 제공함
      • 예 : 스팸 편집 차단, 특정 패턴의 문서 수정 차단 등
  • 취약 지점 : AbuseFilter의 API 모듈 중 하나인 abusefiltercheckmatch action (phabricator.wikimedia.org)
    • 용도 : 특정 조건식(AbuseFilter의 표현식)이
      • AbuseFilter의 로그 항목(logid)이나
      • 최근 변경(rcid)에 매칭되는지 테스트해보는 것
    • 원래 의도 : 필터 작성자가 “이 조건식이 해당 로그에 맞는지?” 테스트하는 것
  • 권한 모델
    • AbuseFilter에는 보호된 변수 개념 존재
      • user_unnamed_ip (임시 계정의 실제 IP) 등을 특정 권한을 가진 사용자만 볼 수 있어야 함
    • 문제는 웹 UI에서는 권한 체크가 되는데, 해당 API(abusefiltercheckmatch)에서는 같은 수준의 권한 체크가 빠져 있어 발생한 취약점

b. 취약 코드 구조​

  • abusefiltercheckmatch API는 다음 입력을 받음
    • logid : AbuseFilter 로그 ID
    • rcid : RecentChange ID
    • match할 조건식 (예: user_unnamed_ip = '1.3.5.7')
  • 내부에서는
    • 해당 logid/rcid에 대해 AbuseFilter 변수들을 로딩하고
    • 조건식을 평가하여 매칭 여부에 대한 결과(true/false)를 API 응답으로 반환함
  • 문제점
    • 이 때, 변수들 중 일부는 보호된 변수이고 원래는 canViewProtectedVariables() 같은 권한을 받은 사용자만 볼 수 있어야 함
    • 하지만 abusefiltercheckmatch에서는 접근하려는 유저가 보호된 변수 열람 가능 권한 여부를 확인하지 않고 그대로 조건 평가에 사용함
  • 패치에서 한 일
    • CheckMatch API 코드에
      • getForbiddenVariables / canViewProtectedVariables 기반의 권한 체크 추가
      • 보호된 변수를 포함한 테스트일 경우
        • 권한 없는 유저는 “permission denied” 에러 반환
        • 권한 있는 유저는 정상적으로 매칭 수행
      • 추가로, 보호된 변수에 대한 Test 시도에 대해 로깅을 추가하여 “시험적으로 값을 때려 맞추는 공격”도 추적 가능하도록 함

c. 공격 플로우(phabricator.wikimedia.org)​

  • 준비 단계

    • 로컬 MediaWiki 환경에 AbuseFilter + CheckUser 확장 설치
    • 임시 계정(temporary account)으로 테스트 편집 수행
    • sysop + checkuser 권한이 있는 계정으로 로그인
    • Special:CheckUser 페이지에서 해당 임시 계정을 조회하여 실제 사용된 IP를 확인 (해당 IP를 1.3.5.7 이라 가정)

  • 필터 설정

    • Special:AbuseFilter/new 페이지에서 새로운 필터 생성 후에

    • 조건식에 아래와 같은 내용을 입력하면

      user_unnamed_ip = '1.3.5.7'

    • 임시 계정으로 다시 편집하여 해당 필터가 로그에 기록되게 함 (AbuseFilterLog entry 생성)

      cf ) 권한이 없는 사용자 시나리오
      → sysop 이지만 checkuser 권한 없는 계정으로 로그인
      → Special:AbuseFilterLog/ID (위 로그의 ID) 페이지를 열면 → “이 로그를 볼 권한 없음” 에러 뜸
      → 이 시점에서 웹 UI는 보호된 변수 접근을 막고 있음

  • 취약 API 악용

    • Special:ApiSandbox 로 이동
    • action=abusefiltercheckmatch 선택
    • logid 에 위 로그 ID 입력
    • 조건식에 다시 넣고 실행 
      user_unnamed_ip = '1.3.5.7'

  • 실제로 일어난 일

    • API 응답에서 “조건이 매칭되었다”고 알려줌
    • 즉, user_unnamed_ip 값이 1.3.5.7 인지 아닌지, 권한 없는 유저가 간접적으로 확인 가능

  • 공격자는 IP 값을 모르는 상태에서

    • user_unnamed_ip = '1.3.5.7'
    • user_unnamed_ip = '2.4.6.8'
    • 등등 계속 바꿔가며 질의 → 맞는 값을 맞출 때까지 반복 → 보호된 변수 값 유추 가능

  • 결과

    • 원래는 CheckUser 권한이 있는 소수의 사용자만 볼 수 있는 IP 정보가 abusefiltercheckmatch API를 통해 일반 sysop 또는 권한 없는 사용자에게 “참/거짓 오라클”로 노출됨
    • 이는 정보 유출(Information Leak) + 권한 정책 붕괴(Access Control Failure)가 동시에 일어난 사례

2. 취약점 위험도 / 심각도 분석 (CVSS 스코어 기반)​

a. 공식 CVSS v3.1 (NVD 기준)​

  • 점수: 9.1 (Critical)
  • 벡터: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (NVD)

b. 각 요소 해석​

  • Attack Vector (AV) : N(Network) → 네트워크를 통해 접근 가능, HTTP(S) API 호출로 충분
  • Attack Complexity (AC) : L(LOW) → API 호출 형식만 알면 됨, 추가적인 race condition 이나 복잡한 조건 필요 없음
  • Privileges Required (PR) : N(No Privileges Required) → “완전 무권한”까지로 보는 평가는 약간 보수적일 수 있지만, 최소한 _일반 사용자 수준_에서 높은 권한 없이도 abusefiltercheckmatch를 호출할 수 있다는 점을 반영했다고 볼 수 있음

c. 결론​

네트워크 상에서 추가 권한 없이,
보호된 AbuseFilter 변수(위에 예시로 보면 임시 계정 IP)에 대한 정보가
‘참/거짓의 오라클’ 형태로 유출되는 Critical 등급의 정보 유출 + 권한 정책이 붕괴되는 사레

3. CVE → CWE 연결 분석​

a. CVE-2025-53499 → CWE-862 : Missing Authorization​

  • NVD 및 Wikimedia 측에서 CWE-862(Missing Authorization) 으로 공식 매핑
  • 즉, 문제의 핵심을 “권한 체크 부재”로 보고 있음

b. CWE-862 (Missing Authorization) 와의 연관성​

  • abusefiltercheckmatch API가
    • 요청을 보낸 사용자가 보호된 변수 값을 볼 수 있는지 → 권한을 확인하지 않고
    • 해당 변수를 포함하는 조건식을 “그대로 평가”해버림
  • 이때 권한 체크가 있었어야 할 위치
    • logid/rcid 기반으로 변수 로드 →
    • 해당 변수 중 “protected variables” 목록 추출 →
    • 현재 사용자의 권한(canViewProtectedVariables) 확인 →
    • 권한 없으면 에러 리턴
  • 하지만 취약 버전에서는 이 과정이 빠져 있었고 → Missing Authorization 그대로인 상태

c. Access Control 붕괴 관점​

  • 원래 의도된 모델
    • CheckUser/특정 권한이 있어야 임시 계정 IP, 일부 신원 관련 변수에 접근 가능
  • 실제 동작(취약)
    • 해당 값을 직접 보여주지는 않지만
    • 조건식 결과를 통해 값의 참/거짓을 확인할 수 있게 됨
  • 즉,
    • Authentication 은 유지된다고 보더라도,
    • Authorization(인가 / 권한 구분)이 완전히 깨진 상태

4. PoC​

a. 개념적 PoC 흐름 요약​

  • 취약 환경 준비
    • MediaWiki 1.43.x + AbuseFilter Extension (취약 버전, < 1.43.2)
    • CheckUser Extension 같이 설치 (IP 관련 보호 변수 사용)
  • 보호된 변수 포함 필터 생성
    • 필터 조건: 
      user_unnamed_ip = '1.2.3.4'
    • 임시 계정으로 편집 → AbuseFilterLog에 기록되게 함
  • 권한 없는 계정으로 API 호출
    • action=abusefiltercheckmatch
    • 파라미터
      • logid=<해당 AbuseFilterLog ID>
      • testfilter=user_unnamed_ip = '1.2.3.4'
    • 응답
      • {"result": "match"} 또는 비슷한 형태로 “매칭됨” 응답
      • 이 과정을 반복하면서 IP 값을 바꿔가며 시도하면 → 실제 IP 값에 도달할 수 있음

b. HTTP 요청 예시 (의사 코드 수준)​

POST /api.php?action=abusefiltercheckmatch&format=json HTTP/1.1
Host: wiki.example.org
Cookie: <권한 낮은 사용자 세션 쿠키>
Content-Type: application/x-www-form-urlencoded

logid=12345
&testfilter=user_unnamed_ip = '1.3.5.7'
  • 응답 (취약 상태 예시)
{
  "abusefiltercheckmatch": {
    "result": "match",
    "details": {
      "matched": true
    }
  }
}
  • matched: true 를 보면
    • “보호된 변수 user_unnamed_ip == '1.3.5.7'” 라는 사실을 권한 없는 유저가 알아낸 것과 동일한 효과

5. 유사 사례 비교​

a. CVE-2024-47913 – AbuseFilter API auth bypass (이전 세대 유사 취약점) (NVD)​

  • 요약
    • AbuseFilter API (abusefiltercheckmatch 관련 모듈)가 로그 상세 정보에 대하여
    • 권한 없이도 필터 조건을 로그에 대해 매칭할 수 있게 해 줌
  • CVE-2025-53499 와의 공통점 :
    • AbuseFilter의 조건식 평가 기능과 권한 체크 누락 조합
    • 직접 값을 보여주지 않지만, 조건 매칭을 통해 민감 데이터를 간접 유추할 수 있다는 패턴
  • CVE-2025-53499 와의 차이점 :
    • 2024 CVE는 주로 로그 상세 정보 권한에 초점
    • CVE-2025-53499는 ‘protected variables’에 대한 권한 모델에 초점
    • 즉, 새로운 영역(보호 변수)에 대한 권한 체크가 빠진 케이스

b. 프로젝트 관점에서 활용 포인트​

  • 동일한 AbuseFilter / abusefiltercheckmatch API를 대상으로
    • 권한 체크 부재가
    • 어떻게 다양한 정보 유출 패턴으로 재등장하는지를
    • 시계열/구조적으로 설명 가능
  • Broken Access Control의 “Information Leak” 유형의 전형적인 진화 사례로 사용하기 좋음

참고문헌​

  • NVD – CVE-2025-53499
    • “Missing Authorization vulnerability in Wikimedia Foundation Mediawiki - AbuseFilter Extension allows Unauthorized Access. … 1.43.X before 1.43.2” (NVD)
  • CVE.org – CVE-2025-53499 Record (cve.org)
  • CVE Details – CVE-2025-53499 – “Unauthorized Inspection of Protected Variables in AbuseFilter” (cvedetails.com)
  • Positive Technologies PT-2025-28247 – 영향 버전/ CVSS 정보 정리 (dbugs.ptsecurity.com)
  • Wikimedia Phabricator – T397196
    • “CVE-2025-53499: AbuseFilter 'abusefiltercheckmatch' API does not check protected variable access restrictions”
    • 재현 절차, 패치 논의 등 핵심 기술 정보 (phabricator.wikimedia.org)
  • MediaWiki Announce 메일링 리스트 – 2025-07-09 Security Release
  • CVE-2024-47913 / GHSA Advisory (AbuseFilter API Auth Bypass)** – 유사 패턴 비교용 (NVD)